Submission Note
What I’d test next if I had more time:

Property-Based Testing: I would implement property-based testing for the dueDate field to ensure the API handles all edge cases of the ISO 8601 format and various time zones.

Security & ID Validation: Currently, the API assumes valid UUIDs. I would add tests to ensure the system handles malformed IDs or SQL/NoSQL injection attempts gracefully.

Race Conditions: Since the data store is in-memory, I'd write stress tests to ensure concurrent requests to PATCH /complete or /assign don't lead to data inconsistency.

Anything that surprised you in the codebase:

Documentation Drift: I was surprised to find that the GET /tasks/stats implementation did not match the documentation. The implementation was missing the total field, which I had to restore and secure with a regression test.

Implicit Status Enums: The validators.js was quite strict about the status being todo, in_progress, or done, yet the README used slightly different terminology in some places. I decided to align everything with the code's internal VALID_STATUSES to ensure consistency.

Questions I’d ask before shipping this to production:

Persistence Strategy: Is there a specific database (SQL vs NoSQL) we plan to migrate to, and should I begin implementing an abstraction layer for the current taskService?

Multi-tenancy/Auth: Will this API need to support multiple users? If so, we need to associate tasks with user IDs and add authentication middleware immediately.